1. Field of the Invention
The present invention relates to a data source transmitting packet data, a device and method for processing stream data to be recorded in a record/regeneration device while making the stream data look like a file, and a reception method in a data sink on an IEEE 1394 bus.
2. Related Art of the Invention
As LSI technology improves, networks where video information and audio information are digitized and transmitted are being developed. Since video signals and audio signals should be regenerated in real time, networks enabling real time transmission are required.
As a network suitable for real time transmission like this, a network called IEEE 1394 is proposed. The IEEE 1394 is a serial high-speed bus system and is compatible with synchronous transmission, thus enabling real time transmission of data.
Currently, the IEEE 1394 is installed as an external interface in digital VCRs for use at home (hereinafter referred to as DVs) as well as many digital audio/video devices (hereinafter referred to as AV devices). As for DVs, for instance, the operation of a DV can be controlled from an external device and data can be transmitted between the external device and the DV by using the IEEE 1394.
On the other hand, also in the personal computer (hereinafter referred to as PC), the IEEE 1394 is coming into widespread use also in the world of PCs by the fact that the IEEE 1394 has been formally supported for Windows 98 of Microsoft that is virtually a standard OS as of 1999, and other OSs. Furthermore, a merger of these PCs and digital audio/video devices with DVs has been pursued.
First, as a first prior art, a data source sending data from the PC to the DV will be described using FIG. 1 to FIG. 7, FIG. 10 and FIG. 11.
FIG. 1 is one example of the data source. In FIG. 1, 101 is a data converting section, 102 is a data buffer, 103 is a descriptor list, 104 is an IEEE 1394 driver, 105 is an IEEE 1394 interface, 106 is an IEEE 1394 bus, 107 is a FIFO, 108 is input data, 109 is a CIP (Common Isochronous Packet) complying with IEC 61883 for example, 110 is a descriptor, 111 is an address on the descriptor list 103 storing the descriptor 110, 112 are start-of-send instructions, 113 is a end-of-send notice and 114 is an isochronus packet.
FIG. 2 is one example of the configuration of CIP data 109 for transmitting data. In FIG. 2, 201 is a packet data and 202 is a CIP header.
FIG. 3 is one example of the configuration of the CIP data 109 for transmitting empty data.
FIG. 4 is one example of the configuration of the isochronus packet. In FIG. 4, 401 is an isochronus header, 402 is a header CRC, and 403 is a data CRC.
FIG. 5 is one example of the configuration of the data buffer 102. In FIG. 5, 501a, 501b, 501c and 501d are frame buffers, and 502a, 502b, 503c and 504d are unsent flags. The data buffer 102 here is configured by four frame buffers.
FIG. 6 is one example of the configuration of the descriptor 110.
FIG. 7 is one example of the configuration of the descriptor list 103. In the descriptor list 103, four descriptors 110 can be stored just as the number of the frame buffers.
FIGS. 10 and FIG. 11 are one example of the configuration of the FIFO 107. In FIG. 10 and FIG. 11, the addresses of the descriptor 110, which are located at the lower hierarchy, were stored later in the FIFO 107. However, in the above described FIG. 1 to FIG. 7, FIG. 10 and FIG. 11, the input data 108 is DV data configured by a plurality of packet data 201. Also, an unsent flag 502a, an unsent flag 502b, an unsent flag 502c and an unsent flag 502d are in a “already sent” or “unsent” condition, and the initial condition is “already sent.”
Operations of data sources according to prior art having a configuration as described above will be explained below.
Upon receiving the input data 108, the data converting section 101 fetches packet data 201 therefrom, adds the CIP header 202 in succession and stores it in the data buffer 102 as the CIP data 109 as shown in FIG. 2. At this time, the CIP data 109 is stored in the frame buffer 501a, in the first place.
Next, when a predetermined number of CIPs 109, for example fourteen CIPs 109 is stored in the frame buffer 501a, the data converting section 101 creates the descriptor 110a in which the method of sending the CIPs 109 stored in the frame buffer 501a, and stores it in the descriptor list 103, as shown in FIG. 6. At this time, the stored addresses 111a of the descriptor 110a in the descriptor list 103 are stored in the FIFO 107 together, and at the same time the send flag 502a belonging to the frame buffer 501a is made “unsent.”
Here, as shown in FIG. 6, “the addresses of the frame buffer 501a,” “the length of the CIP data 109,” “the number of CIPs 109 that are stored in the frame buffer 501a,” “descriptor ID” and “prior information” are stored in the descriptor 110a. The “descriptor ID” contains information for distinguishing the descriptor 110. For example, the “descriptor ID” of the descriptor 110a contains “A,” and the “descriptor ID” of the descriptor 110b contains “B.”
From then on, the data converting section 101 cyclically changes the frame buffer for storage in the order of frame buffer 501b→frame buffer 501c→frame buffer 501d →frame buffer 501a, storing a predetermined amount of CIPs 109 in each frame buffer. At this time, if the unsent flag 502a of the frame buffer in which the CIP data 109 is to be stored next, for example the frame buffer 501a is “unsent,” the data converting section 101 does not perform operations for storage but waits until the unsent flag becomes “already sent.”
Furthermore, after the data converting section 101 stores a predetermined number of CIPs 109 in the frame buffer 501d, it sends the start-of-send start instructions 112 to the IEEE 1394 driver 104 if the start-of-send start instructions 112 are not sent yet to the IEEE 1394 driver 104. At this time, the address of the descriptor 110 stored in FIFO 107 is as shown in FIG. 10.
Next, upon receiving the start-of-send instructions 112 from the data converting section 101, the IEEE 1394 driver 104 refers to the addresses of the descriptor 110a initially stored from the addresses of the descriptor 110 stored in the FIFO 107, and detects the descriptor 110a from the descriptor list 103. Then, according to the content described in the descriptor 110a, CIP s 109 are fetched in succession from the frame buffer 501a, and the isochronus packet 114 as shown in FIG. 4 is created.
Furthermore, the IEEE 1394 driver 104 outputs the created isochronus packet 114 to the IEEE 1394 bus through the IEEE 1394 interface 105.
Next, upon fetching the CIPs 109 in accordance with “the number of the CIPs 109” described in the descriptor 110 from the frame buffer 501a, the IEEE 1394 driver 104 sends the end-of-send notice 113 to the data converting section 101 together with “A” (in this case) that is “descriptor ID” of the descriptor 110a. 
When the above described process is ended, then the IEEE 1394 driver 104 retrieves the FIFO 107, refers to the addresses of the descriptor 110b that it has not referred to yet, and processes the frame buffer 501b corresponding to the descriptor 110b, as in the case of the frame buffer 501a. 
Upon receiving the end-of-send notice 113 from the IEEE 1394 driver 104, the data converting section 101 fetches from the FIFO the addresses of the descriptor 110 located in the lowest hierarchical layer thereof, and discards them. For example, in the case of FIG. 10, the addresses of the descriptor 110a are fetched and discarded, as shown in FIG. 11. At the same time, since “A” representing the descriptor 110a as “descriptor ID” is sent together with the end-of-send notice 113 that is sent to the data converting section 101 at this time, the data converting section 101 rewrites the unsent flag 502a corresponding to the frame buffer 501a to “already sent.”
From then on, data is sent from the PC to the DV by repeating these processes.
Furthermore, in a series of the above described operations, if there is a difference between the transmission rate of the input data 108 and the transmission rate of the IEEE 1394 bus 106, empty data should be sent occasionally in order to adjust the rate. At this time, the data converting section 101 creates the CIP data 109 configured only by the CIP header 202 as shown in FIG. 3, as necessary. In this case, in the case where an immediately preceding CIP data 109 is stored in the frame buffer 501a, even if fourteen CIPs 109 are not stored in the frame buffer 501a, the descriptor 11a for the frame buffer 501a is created and is stored in the descriptor list 103, and the sent flag 501a is made “unsent” in the first place, as described above. Then, the CIP data 109 for empty data is stored in the frame buffer 501b, and the descriptor 110b describing the method of sending CIPs 109 stored together in the frame buffer 501b is created and is stored in the descriptor list 103. Following operations are carried out as in the case of sending CIPs for transmitting DV data.
Now, in the case of personal computers (referred to as PC for short), conventionally, even stream data such as video and audio are treated as files. However, when video and audio are actually recorded, devices such as VTRs for recording them as stream are generally used. To process/edit the video and audio recorded with the VTR, specialized edit equipment can be used, but they are expensive and it is difficult to add means having functions other than those originally prepared to the edit equipment. Thus, it is effective to process/edit data such as video and audio using PC′ software with a PC.
Next, as a second prior art, procedures for carrying out edition with a PC will be described below using FIG. 17. Although PC is specified as an example, equipment other than a PC is similarly used. In FIG. 17, 1 is a PC, and 2 is a stream data record/regeneration device. Although a DV (digital record VTR) is specified as one example of the stream data record/regeneration device 2, the VTR maybe either analog or digital recording, and the I/F may be corresponding to analog or digital forms.
The internal portion of the PC 1 is configured by hardware, software in kernel mode that is an OS (operating system) and software in user mode that is an application. 3 is reception and data format conversion software, 4 is software dealing with audio/video data (edit software can be included as one example), 5 is data format inverse conversion and send software. 6 is software managing files, and 7 is a record/regeneration device recording/generating data that the PC 1 deals with (HDD as one example).
First, data is regenerated with the stream data record/regeneration device, and the needed part of the data that is outputted to the PC 1 is captured in the PC 1 using the reception and data format conversion software 3 that exists in the PC 1. In fact, the reception and data format conversion software 3 converts the data to a file format and writes it in the HDD 7. In fact, the reception and data format conversion software 3 instructs the software 6 managing the File to write File A, thereby writing in the HDD 7 the file converted by the reception and data format conversion software 3. Write is carried out by:                1) File-open instructions-specify the name of the File.        2) Write instructions to the opened file-designate the start-of-write position, the write data size and write data.        3) File close instructions. or repetition thereof. All data of the file is necessarily written, but the order of write and the write size are arbitrary.        
Then, the software 4 dealing with audio/video data instructs the software 6 managing the File to read File A and carries out necessary processes based on the data read from the HDD 7. Usually, in order to write in the HDD 7 the result of the process as new File B, instructions to write File B are made. Furthermore, read of File A is carried out by:                1) File-open instructions-specify the name of the File.        
2) Read instructions to the opened file-designate the start-of-read position, the read data size and read data.                3) File close instructions. or repetition thereof. The order of read and the read size are arbitrary.        
File B generated after processing by the software 4 dealing with audio/video data is converted by the data format inverse conversion and send software 5 to the stream data and is simultaneously recorded in the stream data record/regeneration device 2.
The data format that can be recorded in the stream data record/regeneration device 2 includes, for example, a data format where video and audio that are inputted/outputted from the IEEE 1394 terminal of DV (Digital Video Cassette) defined in the IEC 61834 continue to run in real time. (Unless instructions are sent to the device, the regeneration of data starts approximately when a regeneration button is pushed, and the regeneration of data stops approximately when a stop button is pushed. The record of data starts approximately when a record button is pushed, and the record of data is stopped approximately when a stop button is pushed. If it is a file, the front-end and back-end of the file are strictly defined.)
File formats regarding video and audio that are commonly used include a File format called avi format. This places information about video and audio (such as frame rate of video, number of Frame, screen size, type of video compression, sampling frequency of audio, data rate of audio, sampling number of audio, number of audio channel) at the front-end of the file as header information, then arranges audio data and video data for each unit called Chunk, and places information indicating where each Chunk exists in the file (IndexEntry is generated for each Chunk) at the back-end of the file as index information.
Now, the IEC 61883 is standardized as a protocol for transmitting data of AV devices such as DVs and performing device control using the above described IEEE 1394.
Next, as a third prior art, the method of receiving data outputted from the DV with the PC will be described using FIG. 2, FIG. 4, FIG. 18 to FIG. 24, and FIG. 27 to FIG. 30.
FIG. 18 shows the PC and DV connected on the IEEE 1394 bus. In FIG. 18, 701 is a PC, 702 is a DV, 703 is an application, 704 is a driver for DV, 705 is an IEEE 1394 driver, 706 is an IEEE 1394 interface, 707 is a data outputting section, 708 is an oPCR[0], 709 is an IEEE 1394 interface, 710 is an IEEE 1394 bus, 711 is DV data, 109 is CIP, 714 is operation instructions, 715 is a request to the IEEE 1394 driver 705, 716 is a response to the request 715, and 717 is register data.
FIG. 2 shows an example of a configuration of the CIP data 109. In FIG. 2, 201 is packet data, and 202 is a CIP header. In the CIP header 202, a SID (source node ID) field indicating the node number of the device outputting data, and information showing what data is transmitted are described. The device that receives data can determine who is the send device by referring to the SID field, and is used when management of connections for broadcast transmission and point-to-point transmission described later is performed.
FIG. 4 is an example of a configuration of the isochronus packet. In FIG. 4, 401 is an isochronus header, 402 is a header CRC, and 403 is a data CRC. In the isochronus header 401, the channel for transmitting data is described.
FIG. 19 shows a configuration of the oPCR. As is clear from FIG. 19, in the oPCR, a broadcast connection counter, point to point connection counter, a channel number and the like are described.
FIG. 20 shows a configuration of the iPCR. As is clear from FIG. 20, also in the oPCR, a broadcast connection counter, point to point connection counter, a channel number and the like are described.
FIG. 21 is a conceptual diagram illustrating the broadcast transmission in the IEC 61883. In FIG. 21, 601 is a receiver and 602 is a transmitter.
FIG. 22 is a conceptual diagram illustrating the point to point transmission in the IEC 61883.
FIG. 23 is a conceptual diagram illustrating the condition that the broadcast transmission and the point to point transmission in the IEC 61883 are carried out simultaneously.
FIG. 24 shows one example of values of the oPCR[0] of the transmitter 602 and iPCR[0] of the receiver 601. That is, in FIG. 24, one example of the values of the oPCR[0] of the transmitter 602 and the iPCR[0] of the receiver 601 is shown for initial conditions, conditions of FIG. 21 (conditions of performing broadcast transmission), conditions of FIG. 22 (conditions of performing point to point transmission) and conditions of FIG. 23 (conditions of performing broadcast transmission and point to point transmission at the same time). This will be described later.
FIG. 27 to FIG. 30 are transition tables showing how the values in the oPCR[0] 708 are rewritten. The bcc represents the broadcast connection counter, and the p2p represents point-to-point connection counter.
First, the concept of the broadcast transmission and the point-to-point transmission in the IEC 61883 will be explained.
In the broadcast transmission, as shown in FIG. 21, the transmitter 602 only outputs data to for example a channel number 63 (hereinafter referred to as ch63), and does not care at all about which device receives the outputted data. On the other hand, the receiver 601 only sucks up the data transmitted to the ch63, and is not required to care about which device has outputted the data.
By contrast, in the point-to-point transmission, by clearly defining the sending device and the receiving device, one-to-one data transmission is performed between the transmitter 602 and the receiver 601 as shown in FIG. 22. As necessary, for example, the sending device carries out a plurality of point-to-point transmission at a time, thereby enabling one-to-many transmission.
Also, the broadcast transmission and point-to-point transmission can be performed at the same time. For example, as shown in FIG. 23, the transmitter 602 can output data to the ch63 by broadcast transmission, and at the same time carry out one-to-one transmission to the receiver 601 by point-to-point transmission.
Next, how to perform the broadcast connection and point-to-point connection in the IEC 61883 will be explained.
The transmitter 602 conforming to the IEC 61883 has the oPCR (output plug control register) as a register for control of output. Similarly, the receiver 601 conforming to the IEC 61883 has the iPCR (input plug control register) as a register for control of input. The configuration of the oPCR is as shown in FIG. 19, and the configuration of the iPCR is as shown in FIG. 20. A plurality of oPCRs and iPCRs can be had, and the Nth register is expressed as oPCR[N] or iPCR[N]. In this case, assuming that the Oth register is used, the oPCR[0] of the transmitter 602 and the iPCR[0] of the receiver 601.
First, for the initial condition, namely for the condition that no connection is established, as shown in the columns of the initial condition of FIG. 24, both the bcc and p2p of the oPCR[0] are 0, and similarly both the bcc and p2p of the iPCR[0] are 0. The channel number shall contain 63 as one example of the initial value.
In the case where the transmitter 602 performs output to a channel by broadcast transmission, 1 is assigned to the bcc of the oPCR[0]. Similarly, in the case where the receiver 601 performs input by broadcast transmission, 1 is assigned to the bcc of the iPCR[0]. That is, when the broadcast transmission is performed as shown in FIG. 21, each value of the bcc, p2p and channel number of the oPCR[0] of the transmitter 602 and the iPCR[0] of the receiver 601 is as shown in the column of FIG. 21 in FIG. 24. Of course, in order that the receiver 601 receives the data the transmitter 602 outputs, channel numbers should be same. In the case where the transmitter 602 terminates the output by broadcast transmission, the bcc of the oPCR[0] is turned back to 0. Similarly, in the case where the receiver 601 terminates the input by broadcast transmission, the bcc of the iPCR[0] is turned back to 0.
When the transmitter 602 and the receiver 601 perform transmission in a point-to-point manner, any one of the devices (it may be the transmitter 602 or the receiver 601 or a third device) adds 1 to the p2p of the oPCR[0] of the transmitter 602, and also adds 1 to the p2p of the iPCR[0] of the receiver 601 at the same time. That is, when point-to-point transmission as shown in FIG. 22 is performed, each value of the bcc, p2p, channel number of the oPCR[0] of the transmitter 602 and the iPCR[0] of the receiver 601 is as shown in the column of FIG. 21 of FIG. 24.
Here, transmission is performed with both channel numbers of the iPCR[0] of the receiver 601 and of the oPCR[0] of the transmitter 602 being 63, but the device establishing point-to-point transmission may change both channel numbers of the iPCR[0] of the receiver 601 and of the oPCR[0] of the transmitter 602 to any one of 0 to 62 to perform point-to-point transmission with other channel, if necessary.
When point-to-point transmission between the transmitter 602 and the receiver 601 is terminated, the device establishing the point-to-point connection subtracts 1 from the p2p of the oPCR[0] of the transmitter 602, and also subtracts 1 from the p2p of the iPCR[0] of the receiver 601 at the same time.
In the case where broadcast transmission and point-to-point transmission are performed at the same time, the above described operations may be carried out in a similar way when each connection is established. For example, when the transmitter 602 performs output to the ch63 in a broadcast manner and at the same time transmits data to the receiver 601 in a point-to-point manner as shown in FIG. 23, the values of the bcc and p2p of the oPCR[0] of the transmitter 602 are both 1 as shown in the column of FIG. 23 of FIG. 24. At this time, the value of the p2p of the iPCR[0] of the receiver 601 is 1. However, since the receiver 601 does not necessarily perform reception at a time in a broadcast manner, whether to make the bcc of the iPCR[0] equal 1 or not is up to the receiver 601.
Incidentally, whether it is broadcast transmission or point-to-point transmission, two resources, i.e. channel and bandwidth should be allocated in the case where transmission is performed on the IEEE 1394 bus 710. In the case of IEC 61883, the device that first established any one of connections in a channel allocates these resources, and the device that last disconnected the connection must release these resources.
Now, how data is transmitted from the DV 702 that is a transmitter to the PC 701 will be explained.
First, operations of the DV 702 will be explained.
Upon receiving start-of-regeneration instructions, the DV 702 assigns 1 to the bcc in the oPCR[0] 708. The data outputting section 707 starts outputting the DV data 711 to the IEEE 1394 interface 709. The IEEE 1394 interface 709 adds the CIP header 202 to the packet data 201 into which the received DV data 711 is split to create the CIP data 109 as shown in FIG. 2, and further adds the isochronus header 401, the header CRC 402 and the data CRC 403 to create and output the IEEE 1394 bus 710 the isochronus packet as shown in FIG. 4. The channel that is outputted at this time is dependent on the value written in the channel number of the oPCR [0] 708. In the case where the p2p equals 0, namely none of the connections is established just before the bcc is turned to 1, the IEEE 1394 interface 709 allocates the channel written in the channel number and a necessary bandwidth before starting output to the IEEE 1394 bus 710.
Upon receiving stop-of-regeneration instructions, the DV 702 turns back the bcc in the oPCR[0] 708 to 0, the data outputting portion 707 stops output to the IEEE 1394 interface 709, and the IEEE 1394 interface 709 stops output to the IEEE 1394 bus 710. At this time, when the bcc and the p2p are both 0 and none of the connections is established, the IEEE 1394 interface 709 releases the resource of the allocated channel and bandwidth.
Next, operations of the PC 701 will be described.
Upon receiving start-of-reception instructions as operation instructions 714 from the application 703, the driver 704 for DV sends a request to obtain the value of the oPCR of the DV 702 to the IEEE 1394 driver 705, as the request 715. The IEEE 1394driver 705 requests the IEEE 1394 interface 709 to send the register data 717 in the oPCR [0] 708 through the IEEE 1394 interface 706. Upon receiving a send request, the IEEE 1394 interface 709 fetches the register data 717 from the oPCR[0] 708 and sends the same to the IEEE 1394 interface 706. The IEEE 1394 driver 705 outputs the register data 717 received by the 1394 interface 706 to the driver 704 for DV, as the response 716.
The driver 704 for DV views the content of the register data 717, and if the bcc of the oPCR[0] 708 equals 1, or the p2p is 1 or larger, it sends instructions to write the data obtained by assigning the value obtained by adding 1 to the value of the p2p in the oPCR[0] 708 to the p2p of the oPCR[0] 708 in the oPCR[0] as new register data 717 to the IEEE 1394 driver 705 as the request 715. Upon receiving instructions to write the register data 717 in the oPCR[0] 708 as the request 715, the IEEE 1394 driver 705 requests the IEEE 1394 interface 709 to rewrite the register data 717 in the oPCR [0] 708 through the IEEE 1394 interface 706. Upon receiving the write request, the IEEE 1394 interface 709 writes the new register data 717 in the oPCR [0] 708 if the new register data 717 is reasonable value.
After that, the Driver 704 for DV sends instructions to start receiving data from the value indicated by the channel number in the oPCR [0] 708, for example ch63 to the IEEE 1394 driver 705 as the request 715. Upon receiving the start-of-reception unstructions as the request 715, the IEEE 1394 driver 705 starts receiving the isochronus packet being data from the ch63 on the IEEE 1394 bus 710 trough the IEEE 1394 interface 706. The IEEE 1394 driver 705 fetches the CIP data 109 from the received isochronus packet and outputs the CIP data 109 to the driver 704 for DV. The driver 704 for DV fetches the packet data 201 from the CIP data 109, creates the DV data 711 from the packet data 201, and outputs the same to the application 703.
Also, the driver 704 for DV views the content of the register data 717, and if both the bcc and p2p of the oPCTR[0] 708 are 0, it sends instructions to write the data obtained by assigning the channel that other devices does not use in the IEEE 1394 bus 710, for example ch0 to the channel number in the oPCR [0] 708, and assigning the value obtained by adding 1 to the value of the p2p in the oPCR [0] 708 to the p2p of the oPCR [0] 708 in the oPCR [0] 708 as new register data 717 to the IEEE 1394 driver 705 as the request 715. Upon receiving instructions to write the register data 717 in the oPCR [0] 708 as the request 715, the IEEE 1394 driver 705 requests the IEEE 1394 interface 709 to rewrite the register data 717 in the oPCR [0] 708 through the IEEE 1394 interface 706. Upon receiving the write request, the IEEE 1394 interface 709 writes the new register data 717 in the oPCR [0] 708 if the new register data 717 is reasonable value. At the same time, the driver 704 for DV allocates the ch0 and a necessary bandwidth that are resources of the IEEE 1394 bus 710, and then sends instructions to start receiving data from the ch0 to the IEEE 1394 driver 705 as the request 715. Upon receiving start-of-reception instructions as the request 715, the IEEE 1394 driver 705 starts receiving the isochronus packet that is data from the ch0 on the IEEE 1394 bus 710 through the IEEE 1394 interface 706. In the case where DV 702 has not outputted the data, the IEEE 1394 driver 705 waits until the data is outputted.
Following operations are similar to those in the case that the bcc of the oPCR[0] 708 equals 1.
On the other hand, upon receiving stop-of-reception instructions as the operation instructions 714 from the application 703, the driver 704 for DV sends instructions to stop receiving data from the IEEE 1394 bus 710 to the IEEE 1394 interface 706 as the request 715. Upon receiving stop-of-reception instructions, the IEEE 1394 interface 706 stops receiving data from the IEEE 1394 bus 710.
Next, upon receiving stop-of-reception instructions as the operation instructions 714 from the application 703, the driver 704 for DV sends to the IEEE 1394 driver 705 as the request 715 a request to obtain the value of the oPCR[0] 708 of the DV 702. The driver 704 for DV sends instructions to write the data obtained by assigning the value obtained by subtracting 1 from the value of the p2p in the oPCR[0] 708 to the p2p of the oPCR[0] 708 in the oPCR[0] 708 as new register data 717 to the IEEE 1394 driver 705 as the request 715. By operations similar to those described above, the value of the oPCR[0] 708 of the DV 702 is changed. If the bcc of the oPCR[0] 708 equals 0 and the driver 704 for DV allocates the resource of the IEEE 1394 bus 710 earlier, the driver 704 for DV then releases the resource of the IEEE 1394 bus 710 at the same time. At this time, if necessary, the driver 704 for DV turns the value of the channel number of the oPCR[0] 708 to the original value.
Tables of who allocates the value of the oPCR[0] 708 of the DV 702 and the resource of the IEEE 1394 bus 710, and who release the same are shown in FIG. 27 to FIG. 30 as one example.
Totally, four possible operations are assumed, considering which of start-of-regeneration of the DV 702 and start-of-reception of the PC 701 was performed earlier, and which of stop-of-regeneration of the DV 702 and stop-of-reception of the PC 701 was performed earlier.
FIG. 27 shows the case where start-of-reception of the PC 701 and stop-of-regeneration of the DV 702 are performed earlier. When the PC 701 starts reception, the bcc and p2p of the oPCR[0] 708 are both 0 because regeneration of the DV 702 has not been started yet. Thus, the PC 701 changes the channel number of the oPCR[0] 708 to ch0 and the p2p to 1, and allocates the resource of the IEEE 1394 bus 710. When the DV 702 starts regeneration, the resource is not allocated and the bcc is changed to 1 because the p2p is already 1, namely the point-to-point connection is already established.
When the DV 702 stops regeneration, the resource is not released and the bcc is turned back to 0 because the p2p is still 1, namely the point-to-point connection is being established.
When the PC 701 stops reception, the PC 701 turns the channel number of the oPCR[0] 708 back to ch63, and turns the p2p back to 0 at the same time. At this point, since the DV 702 is not regenerated, the bcc of the oPCR[0] 708 is also 0. Thus, the PC 701 releases the resource of the IEEE 1394 bus 710.
FIG. 28 shows the case where start-of-reception of the PC 701 and stop-of-reception of the PC 701 are earlier. When the PC 701 starts reception, the bcc and p2p of the oPCR[0] 708 are both 0 because regeneration of the DV 702 has not been started yet. Thus, the PC 701 changes the channel number of the oPCR[0] 708 to ch0 and the p2p to 1, and allocates the resource of the IEEE 1394 bus 710. When the DV 702 starts regeneration, the resource is not allocated and the bcc is changed to 1 because the p2p is already 1, namely the point-to-point connection is already established.
When the PC 701 stops reception, the PC 701 turns the channel number of the oPCR[0] 708 back to ch63, and also turns the p2p to 0 at the same time. At this point, since the DV 702 is still regenerating, the bcc of the oPCR[0] 708 is 1. Thus, the PC 701 does not release the resource of the IEEE 1394 bus 710.
When the DV 702 stops regeneration, the bcc is turned back to 0, but since the p2p is also already turned to 0 and none of the connections is established, the DV 702 releases the resource of the IEEE 1394 bus 710.
FIG. 29 shows the case where start-of-regeneration of the DV 102 and stop-of-reception of the PC 701 are earlier. When the DV 702 starts regeneration, the DV 702 allocates the resource and further turns the bcc to 0 because the p2p is still 0, namely point-to-point connection is not established.
When the PC 701 starts reception, regeneration of the DV 702 is already started, and the bcc of the oPCR[0] 708 is 1. Thus, the PC 701 only changes the p2p of the oPCR[0] 708 to 1, neither changing the channel number nor securing the resource of the IEEE 1394 bus 710.
When the PC 701 stops reception, the PC 701 turns the p2p of the oPCR[0] 708 back to 0. At this point, since the DV 702 is still regenerating, the bcc of the oPCR [0] 708 is 1. Thus, the PC 701 is not required to release the resource of the IEEE 1394 bus 710.
When the DV 702 stops regeneration, the bcc is turned back to 0, but since the p2p is also already turned to 0 and none of the connections is established, the DV 702 releases the resource of the IEEE 1394 bus 710.
FIG. 30 shows the case where start-of-regeneration of the DV 702 and stop-of-reception of the DV 702 are earlier. When the DV 702 starts regeneration, the DV allocates the resource and further turns the bcc to 1 because the p2p is still 0, namely point-to-point connection is not established yet.
When the PC 701 starts reception, the regeneration of the DV 702 is already started, and the bcc of the oPCR[0] 708 is 1. Thus, the PC 701 only changes the p2p of the oPCR[0] 708 to 1, neither changing the channel number nor securing the resource of the IEEE 1394 bus 710.
When the DV 702 stops regeneration, the resource is not released and the bcc is turned back to 0 because the p2p is still 1, namely the point-to-point connection is being established.
When the PC 701 stops reception, the PC 701 turns the p2p of the oPCR[0] 708 back to 0. At this point, since the DV 702 does not regenerate, the bcc of the oPCR[0] 708 is also 0. At this time, the PC 701 needs to release the resource of the IEEE 1394 bus 710, but since the IEEE 1394 driver 705 and the driver 704 for DV have characteristics that they cannot resources other than those allocated on their own, the resource cannot be released.
That is, generally, devices connected to the IEEE 1394 bus 110 such as DV 102 can release resources that other devices have allocated. By contrast, the PC 101 provided with Window 98 thereon has characteristics that they can release resources allocated on their own, but cannot release resources allocated by other devices.
As described above, in the IEC 61883, the device that first established any one of connections in a channel allocates these resources and the device that last disconnected the connection must release these resources. Therefore, the PC 701 must release the resource if complying with the IEC 61883, but the resource can not be released due to the characteristics of the PC 701.
Once the resource is not properly released, the resource can not be used again unless a bus reset is generated in the IEEE 1394 bus 710.
Operations of data sources according to the first prior art have been described above, but in the above described configuration, all the addresses of the descriptor 110 stored in the descriptor list 103 are stored in the FIFO 107. In this case, if the number of addresses of the descriptor 110 to be stored in the FIFO 107 increases, then the amount of memory in the PC used by the IEEE 1394 driver 104 also increases.
Inversely, if the number of addresses of the descriptor 110 to be stored in the FIFO 107 is decreased, namely the number of frame buffers in the data buffer 102 decreases, then a possible range of accepting the jitter of the input data 108 to be inputted in the data converting section 101 becomes narrower. In this case, if the input data 108 to be inputted in the data converting section 101 has a certain degree of delay or more, for example, the IEEE 1394 driver 104 could not send the isochronus packet 114 continuously.
That is, in a conventional data source, there is a problem (first problem) that some trade-off relationship is formed between the stability of send and the amount of memory required by the PC.
Also, in methods or devices described for the second prior art, processes by the reception and data format conversion software 3 and processes by the data format inverse conversion and send software 5 should be further executed before and after the software 4 dealing with audio/video data, which is complicated.
However, since data that is dealt with by the stream data record/regeneration device 2 is stream data and not a file format (namely, it does not have header information and index information), and in the PC 1, the software 4 dealing with audio/video data makes access to recording media including the HDD 7 in the first place in asynchronous timing as well as to arbitrary data, making a direct access to the stream data record/regeneration device 2 that generally performs record/regeneration in real time does not help obtain needed data.
In the case where the software 4 dealing with audio/video data only wants to process data recorded in the stream data record/regeneration device 2 and write the result in the HDD of the PC, and inversely, in the case where the software 4 dealing with audio/video data only wants to process the data in the HDD of the PC and write the result in the stream data record/regeneration device, itis similarly complicated, and HDD capacity is required.
Furthermore, for capturing a large amount of audio/video data (for example, more than 1 GB for five minute data) in the HDD 7, a HDD of large capacity is required. If data can be accumulated in the HDD, it is inevitably captured by the reception and data conversion software temporarily, but data should be replaced soon because the capacity of the HDD is soon exhausted, which is very complicated.
Prior arts have the above described problems.
That is, there is the problem (second problem) that procedures and devices for editing video and audio recorded in the stream data record/regeneration by PC device are complicated.
Furthermore, there is the problem (third problem) that an access cannot be made from the software editing video and audio of the PC directly to the video and audio recorded in the stream data record/regeneration device.
Furthermore, there is the problem (fourth problem) that a HDD of large capacity is required when the video and audio of the PC are edited.
Furthermore, in the conventional configuration described for the third prior art, there is the problem (fifth problem) that release of resources of the IEEE 1394 bus cannot be carried out properly and after that, these resources cannot be used if operations are performed in the order shown in FIG. 30.